1. Field of the Invention
This invention generally relates to files registry in multiple computer systems. More specifically, the invention relates to files registry creation and management.
2. Background Art
User/group management operations in many operating systems, such as AIX and other flavors of UNIX and Linux, commonly used on multiple computer systems do not allow on a single host the creation and management of plural (or alternate) user/group data files, commonly referred to as the files registry (also referred to as the user data repository). The files registry includes files containing the user names, user ids, group names, group ids, user passwords, and other per-user attribute data (like account_locked), as found in the files /etc/passwd, /etc/security/passwd, /etc/group, /etc/security/group, and /etc/security/user on AIX.
Existing files registry user management tasks, including making users/groups, deleting users/groups, password management, and changing attributes of users/groups, impose changes to a single set of files, which are global to a host, thus precluding the administrator from establishing plural or multiple sets of files registry that can be tailored and distributed to different sets (or types) of node groups within a cluster.
If an administrator wants a different files registry on one or more nodes, then the administrator can: (1) manage the files registry on per-host basis; (2) define “master” files registry hosts, manage the files registry on each master host, and then distribute each master files registry to other hosts; or (3) maintain user/group data in a separate, centralized data base, push out to each host on a per-host basis the data that fits the host's user policy profile, and then “assemble” the data as the local files registry. Each option is time consuming, cumbersome, requires administrator intervention in some cases, is prone to synchronization errors, does not provide a seamless administrative user management experience, and is difficult to audit/track.
In the case of the second option, the files registry on each master host still must be distributed to all other nodes of similar type (i.e., the files registry on the master login node still has to be distributed to all other login nodes, and so forth.). Also, with this option, the files registry on each master host could be stored in a mountable file system and then mounted by other nodes. Unfortunately, if the mount operation fails, there is no files registry and user access to a host is not permitted. In the case of the third of the above-identified options, custom scripts are required, separate data input/maintenance of the database is required, and host-profiles must be established.